The ability to recover rapidly from network failures is one of the most sought network characteristics. There are few solutions that address this issue to satisfaction. One such solution is IP Fast Re-Route (IPFRR) described in RFC (Request For Comments) 5714. IPFRR mimics the solution of MPLS-FRR (Multi-Protocol Label Switching-Fast Re-Route), with the exception that MPLS-FRR is path based, or source routing based in other words. This implies that the re-route decision can be carried out by the PLR (point-of-local-repair) router alone, without cooperation of other LSRs (Label Switched Routers) in the network. IP based FRR, however, is by nature not source routing based. As a result, its re-route decision may not be honored by other routers in the network which can lead to severe consequences such as traffic outage or routing loops.
There have been several methods proposed around the IPFRR concept. One method is LFA (Loop Free Alternative) described in RFC 5286. The LFA approach requires a great amount of computation and has coverage issues. Another method is Not-Via, described in IETF draft “draft-ietf-rtgwg-ipfrr-notvia-address-06”, Oct. 21, 2010. The Not-Via approach is complicated and is prohibitive to be useful. The primary reason for difficulties in the approaches proposed around the IPFRR concept is evident from the following passage of RFC 5714, first paragraph, section 1: “However, there is an alternative approach, which is to compute backup routes that allow the failure to be repaired locally by the router(s) detecting the failure without the immediate need to inform other routers of the failure.” The phrase “without the immediate need to inform other routers of the failure” is against the nature of the IP network in which the domain-wide synchronization is the key.
In general, in normal link state routing operations, upon a router detecting a link failure or other network disruption, the router floods a notification to all of its surrounding neighbor routers, which after some processing (e.g., updating the routing and/or forwarding table), propagate the information further to other routers until every router is updated and synchronized. This flooding mechanism is slow and takes a relatively long amount of time to complete and is dependent to the network structure and size.